Method, device and system for information verification

ABSTRACT

The present application discloses methods, devices and systems for information verification, and in particular for multi-user verification for transactions such as online payment transactions. An online account, such as a payment account, can be registered as a multi-user verification account, which requires at least two users to verify a transaction. After receiving a verification request from a first user, a server verifies first verification information (e.g. voiceprint information) from the first user and second verification information (e.g. voiceprint information) from the second user, so that the server may approve or deny the pending transaction in accordance with a comparison of the first and second verification information against respective verification information stored in association with the multi-user verification account.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 14/444,908, entitled “METHOD, DEVICE AND SYSTEM FORINFORMATION VERIFICATION”, filed on Jul. 28, 2014, which is acontinuation of PCT Patent Application No. PCT/CN2014/077147, entitled“METHOD, DEVICE AND SYSTEM FOR INFORMATION VERIFICATION” filed on May 9,2014, which claims priority to Chinese Patent Application No.201310530347.2, “METHOD, DEVICE AND SYSTEM FOR INFORMATIONVERIFICATION.” filed on Oct. 30, 2013, all of which are herebyincorporated by reference in their entirety.

FIELD OF THE TECHNOLOGY

The present application relates to the computer technical field,especially relates to a method, device and system for informationverification.

BACKGROUND OF THE TECHNOLOGY

At the present, people usually go through a verification process for theuser's identity when conducting online transactions. The user's propertysecurity is protected through using the result of identity verificationto determine whether to start and/or complete a transaction. In theexisting technology, the identity verification in the payment process isgenerally limited to providing the payment account informationregistered by the user and verify the corresponding preset password. Inmost of the information verification processes for payment, theverification is successful as long as the payment account and passwordsubmitted by the user are consistent to the account and password savedby the server; and upon successful verification, the present user isauthorized to carry out the operations such as payment and deductionspecifically requested by the user.

In the existing technology, in order to further guarantee paymentsecurity, “security code protection” information provided by a codegenerating device or object, or random verification code in averification message sent to an authorized user's phone number can beprovided by the user in general after the user submits the paymentaccount information and password. However, if the device or objectproviding the “security code protection” information or the authenticuser's phone is stolen by an illegitimate user, the illegitimate usercan easily complete an illegal transaction after obtaining the authenticuser's account and password, resulting in the property loss of theauthentic user.

SUMMARY

The above deficiencies and other problems associated with the existingtechnology are reduced or eliminated by the method, device, and systemdisclosed below. In some embodiments, the present application isimplemented in a computer system that has one or more processors, memoryand one or more modules, programs or sets of instructions stored in thememory for performing multiple functions. Instructions for performingthese functions may be included in a computer program product configuredfor execution by one or more processors.

One aspect of the present disclosure involves a computer-implementedmethod performed by a computer system to conduct multi-user verificationfor online transactions using an instant messaging (IM) application,wherein the IM application having a plurality of IM accounts. The methodincudes: receiving a first message including a verification request froma first user at a first electronic device running the IM application,wherein the verification request comprises transaction information for apending online transaction and first verification information and firstbiometric information associated with the first user, wherein thetransaction information identifies the first user as a primary verifierand at least one second user as at least one additional verifier for thepending online transaction; in response to the verification request fromthe first user, comparing the first biometric information againstprestored first reference biometric information associated with thefirst user in association with the first IM account; sending a secondmessage requesting additional confirmation for the pending onlinetransaction from the at least one second user at a second electronicdevice running the IM application after the first biometric informationpassing the comparison; receiving a third message including secondverification information from the at least one second user at the secondelectronic device running the IM application, wherein the secondverification information is provided in response to the request foradditional confirmation from the server; and verifying the pendingonline transaction in accordance with a comparison of the firstverification information and second verification information againstrespective verification information stored in association with the firstuser and the at least one second user.

Another aspect of the present application involves a computer systemsuch as a server. The server comprises memory, one or more processors,and one or more program modules stored in the memory and configured forexecution by the one or more processors to perform the method describedherein. Another aspect of the present application involves anon-transitory computer readable storage medium having stored thereininstructions, which when executed by a computer system, cause thecomputer system to perform the method described herein.

Some embodiments may be implemented on either the terminal side or theserver side of a terminal-server network environment.

BRIEF DESCRIPTION OF THE DRAWINGS

The aforementioned features and advantages of the present application aswell as additional features and advantages thereof may be more clearlyunderstood hereinafter as a result of a detailed description ofpreferred embodiments when taken in conjunction with the drawings.

FIG. 1 is a flow chart illustrative of the information verificationmethod according to some embodiments:

FIG. 2 is a flow chart illustrative of the information verificationmethod according to some embodiments of the present application, showingmore details;

FIGS. 3A and 3B are exemplary user interfaces of the firstclient-terminal and second client-terminal during the verificationprocess according to some embodiments;

FIGS. 4A and 4B are exemplary user interfaces of the secondclient-terminal during the registration process according to someembodiments:

FIG. 5 is a flow chart illustrative of the information verificationmethod according to some embodiments;

FIG. 6 is a flow chart illustrative of the information verificationmethod as performed by a server according to some embodiments;

FIG. 7 is a flow chart illustrative of the information verificationmethod as performed by a second client terminal according to someembodiments;

FIG. 8 is a flow chart illustrative of the information verificationmethod as performed by a server according to some embodiments;

FIG. 9 is a schematic illustration of an information verificationmethod, showing how a first client-terminal, a second client-terminal,and a server interact according to some embodiments;

FIG. 10 is a schematic structural diagram of an information verificationsystem in a network environment according to some embodiments:

FIG. 11 is a block diagram of an information verification apparatus,such as a server, according to some embodiments;

FIG. 12 is a block diagram of an information verification apparatus,such as a second terminal associated with the first client-terminal,according to some embodiments;

FIG. 13 is a schematic structural diagram of an information verificationapparatus, such as a server, according to some embodiments;

FIG. 14 is a schematic structural diagram of another informationverification apparatus, such as a second terminal associated with thefirst client-terminal, according to some embodiments.

Like reference numerals refer to corresponding parts throughout theseveral views of the drawings.

DESCRIPTION OF EMBODIMENTS

Reference may now be made in detail to embodiments, examples of whichare illustrated in the accompanying drawings. In the following detaileddescription, numerous specific details are set forth in order to providea thorough understanding of the subject matter presented herein. But itmay be apparent to one skilled in the art that the subject matter may bepracticed without these specific details. In other instances, well-knownmethods, procedures, components, and circuits have not been described indetail so as not to unnecessarily obscure aspects of the embodiments.

FIG. 1 is a flow chart illustrative of the information verificationmethod according to some embodiments of the present application. In someembodiments, the method includes:

S101: Based on the payment account, the first client-terminal sends thefirst verification information to a server, and the first verificationinformation is used for making payment verification for the verificationrequest submitted.

The client-terminal may be any computing device such as mobile deviceshaving network function such as tablet computer, smart phone, e-reader,remote control, vehicle device and wearable device; through the firstclient-terminal, the user can browse various e-commerce platforms andobtain relevant commodities and services.

The user of the first client-terminal completes the payment transactionthrough a registered payment account. The payment account in someembodiments can be a registered account for a single user or a paymentaccount shared by multiple users. The information verification methodmay be used to verify the user making the transaction in both types ofscenarios. In some embodiments, the first client-terminal is associatedwith the payment account. In some embodiments, the first client-terminalis a communication account (e.g., a user account on a social networkplatform) that can function as a payment account (e.g., through linkingto a payment account at a financial service provider).

After obtaining the verification request from the user, the firstclient-terminal initiates the payment process which firstly needs theuser to submit information for verification, and the payment processinvolving accounts transfer may be executed after passing theverification. Through the first client-terminal, the user sends thefirst verification information used for making payment verification forthe verification request submitted to the server based on the paymentaccount. The first verification information can include physiologicalbiometric information related to biometrics such as but not limited to:finger print, iris, face features, voice print, nucleotides such as DNA,palm print, hand geometry, retina, and odor/scent.

S102: The server sends the payment confirmation request to the secondclient-terminal corresponding to the associated communication account ofthe payment account after the verification for the first verificationinformation is passed.

In some embodiments, the second client terminal is a client terminalassociated with another user that the user of the first client terminalhas designated as a verifier for the payment transaction. In someembodiments, the second client-terminal can be associated with acommunication account that has already used the payment account, e.g.,when the second client-terminal has logged in an instant messaging (IM)account associated with the payment account or phone number, or when thesecond client-terminal has already used the associated telephone numberof the payment account.

In some embodiments, when the server conducts verification for the firstverification information, it firstly extracts the embedded informationused for verification and conducts analysis; a simple method isverifying whether the embedded information used for verification isconsistent with the saved information for this payment account in theserver (or other user server) or not. If yes, the verification ispassed. For example, with regard to the voice information included inthe first verification information, firstly, the server extracts thevoice information, obtains the voiceprint information such as frequencyand amplitude of the voice information through analysis, getting thevoiceprint information, compares the obtained voiceprint informationwith the preset voiceprint of the payment account and determines whetherthe verification is passed according to the comparison results, sincethe voiceprint information of different people are definitely different,this method can more effectively determine the current operation is theoperation by an authorized user.

In some embodiments of the present application, the second verificationneeds to be executed after the first verification information is passed.Based on account-type, the server can determine whether the involvedtransaction of this payment account needs to be verified by multiplepersons, or the server can check whether this payment account includesmultiple associated communication accounts or not. If yes, thisindicates that the involved transaction of this payment account needs tobe verified by multiple persons. As used herein, the payment accountthat includes multiple associated communication accounts of multipleusers as additional verifiers for a transaction of the payment accountis a type of multi-user verification account.

In some embodiments, the S102 may include: the server conductsverification for the first verification information; if the verificationis passed, the server searches for the associated communication accountconfigured for the payment account; the server sends the paymentconfirmation request to the second client-terminal corresponding to theassociated communication account determined by the searches.

After determining that the involved transaction of this payment accountneeds to be verified by multiple persons, the server searches for theassociated communication account configured to be the additionalverifiers for the payment account again, and the associatedcommunication account can be the account of an instant messaging (IM)program or a phone number, or other accounts that are in controlled bythe second verifier. In some embodiments, this second verifier can be asupervisor, or a guardian of child, that have the right of supervisingthe property of this payment account. In some embodiments, the secondverifier can the husband, wife, or friend, that jointly possess theproperty of this payment account. In some embodiments, the secondverifier has the power to approve or deny the transaction because thefirst user has consented to such authorization. When the server confirmsthat the transaction needs to use the property in the payment account,it sends the verification request to request the second verificationinformation.

In addition to a second verifier, the associated communication accountsmay include multiple accounts corresponding to multiple verifiers. Theserver may send the payment verification request to more than onecommunication account, wherein payment confirmation request carries thepayment information. The payment information is generated according tothe transaction, including information such as but not limited to itemdescription and payment amount.

S103: The second client-terminal responds to the payment confirmationrequest and returns the second verification information to the server.

The second client-terminal of each associated communication account mayreceive the corresponding payment confirmation request, and whether toconsent to this payment is determined by the user of the secondclient-terminal based on contents of the payment confirmation request.In some embodiments, the user of the second client-terminal is availableto reply with voice information through instant voice communication, orreply to the server with matching verification information for the userof the second client-terminal based on a link in payment confirmationrequest.

After the collection of such relevant information as voice andfingerprint, the second client-terminal returns to the server the secondverification information including the collected relevant information.

S104: The server conducts the verification of the second verificationinformation; if the verification passes, the server may perform thepayment operation for the payment account according to the verificationrequest submitted by the first client-terminal.

In some embodiments, the server verifies the second verificationinformation based on the second verification information and through theassociated communication account corresponding to the returned secondverification information; if the second verification information isconsistent with stored information corresponding to this associatedcommunication account of the payment account, then it passesverification. After the second verification is passed, the serverperforms payment operation for the payment account based on verificationrequest submitted by the first client-terminal, and the detailed paymentprocess can be implemented with steps such as but not limited to fundtransfer and order confirmation.

In some embodiments, it should be noted that relevant steps performed bythe aforementioned first client-terminal and each second client-terminalcan be achieved through adding corresponding functional modules to suchapplications as IM application, e-mail application and so on. In someembodiments, the first client-terminal can log in the firstcommunication account; the second client-terminal can log in thecorresponding second communication account; the first communicationaccount and second communication account can be configured to be theassociated communication accounts of the payment account in advance.When the two or more communication accounts of two or more users arelinked with the payment account, the users of the two or morecommunication accounts are notified when a transaction of the paymentaccount needs to be verified, and each user can provide the necessaryverification information (e.g., their own voice or fingerprints).According to this implementation, when a certain party needs to executethe payment operation with the payment account, the server can executethe payment operation such as deducting money after all multiple partiescorresponding to the associated communication account of this paymentaccount pass the verification. The embodiment of the present applicationcan also be implemented through providing a short message including alink that can link to relevant service of the server according to themethods such as short message, and the associated communication accountof the payment account may be the telephone number of the correspondinguser.

In some embodiments, when payment account replenishment is required, themethod of the present application can also include: the server initiatesthe process where the sum of money is transferred to the payment accountin response to the replenishment request when receiving the request forreplenishing the payment account; herein, the replenishment requestincludes the request for transferring a certain amount into the paymentaccount sent by the first client-terminal and/or the secondclient-terminal.

The initiated replenishment process includes interaction with devicessuch as bank server corresponding to replenishment account, update ofaccount information of payment account and other steps includingtransfer prompt and verification.

In some embodiment of the present application, one or multipleassociated communication accounts based on prior configuration maycomplete the verification for the user's payment by verifyingverification information from two communication accounts; this makes theverification for the user's identity more reliable during the paymentprocess; as long as the relevant information of one of the authenticusers related to the communication accounts is not stolen, anun-authorized user cannot complete the verification of the paymentaccount. This method is easy to be implemented in the client-terminal,is convenient for the user to complete the user verification simply andrapidly, and ensures the security of the user's payment account andproperty.

FIG. 2 is a flowchart illustrative of the information verificationmethod according to some embodiments, showing more details. The methodcan be implemented by interaction between user terminals and the server.In some embodiments, the method includes:

S201. When the server detects that at least two associated communicationaccounts are configured to verify the registered payment account, andevery associated communication account has corresponding voiceauthentication information, the server labels this payment account as amulti-user verification account.

In some embodiments, each user can complete the registration of thecorresponding associated communication account of the payment accountand the authentication information in the server before verification.The user can also complete the registration of the correspondingassociated communication account of the payment account and theauthentication information in the other register servers; meanwhile, theserver may identify the relevant payment account and its correspondingassociated communication account and authentication information, andcompletes the labeling of such payment accounts according to these.

S202: The server stores the payment account labeled as the multi-userverification account, its associated communication accounts and thephysiological biometric information (e.g., voice authenticationinformation) corresponding to the respective user of every associatedcommunication account.

The server can store the payment account, its associated communicationaccounts and the authentication information corresponding to everyassociated communication account in the form of a mapping table, so thatit can directly find the associated communication account and theauthentication information corresponding to every associatedcommunication account upon verification through searching the table.

The aforementioned is the registration process of the relevantinformation of payment account in the server in some embodiments of thepresent application. This registration process can be completed at anytime before the payment account initiates payment. Based on thisregistration, the server completes the following relevant steps inaccordance with some embodiments.

S203: The server conducts verification for the payment account andpassword information submitted by the first client-terminal.

In some embodiments, when the user of the first client-terminal selectsto purchase a certain commodity or service, the user can submit thecorresponding payment account and password information to be used forcompleting this payment to the server; the server may firstly conductinitial verification for the payment account and password submitted bythe first client-terminal. After this initial verification is passed,the server then triggers the first client-terminal to submit the firstverification information-execute the following S204. If this initialverification is not passed, the server normally sends a prompt messagethat the input payment account or password is wrong. In someembodiments, the server may prompt the user to enter the payment accountand password information again. The server can trigger theclient-terminal to display a first verification information obtaininginterface through sending a first verification request, so that the usercan input the verification information used for the first verificationin this first verification information obtaining interface. An exemplaryscreen shot of this first verification information obtaining interfaceis shown in FIG. 3A.

As shown in FIG. 3A, the first client-terminal may display a firstinformation obtaining interface, which may prompt the user of the firstclient-terminal to input verification information. Here, the inputverification information is voice information; thus, the firstinformation obtaining interface is prompting the user to “Press totalk,” so that the first client-terminal may gather the voiceinformation from the user. In some embodiments, the firstclient-terminal may analyze the voice information and extract thevoiceprint information and send the voiceprint to the server as thefirst verification information. In some embodiments, the firstclient-terminal may simply send the voice information to the server asthe first verification information so that the server may extract thevoiceprint information. It should also be noted that the verificationinformation may be other types of information. In some embodiments, theverification information may be biometric information, such as but notbe limited to information related to: finger print, iris, face features,nucleotides such as DNA, palm print, hand geometry, retina, andodor/scent. For example, the first information obtaining interface mayprompt the user to “scan left index finger fingerprint,” so that theuser may use the first client-terminal or any associated device to scanthe designated fingerprint. In some embodiments, as shown in FIG. 3A,the first client-terminal may further display a “Cancel Transaction”button, allowing the user of the first client-terminal to cancel thetransaction without entering the verification information. It should benoted that the specific design of the display of the firstclient-terminal may vary according to a default design andconfigurations by the user.

S204: Based on the payment account, the first client-terminal sends thefirst verification information to the server, and the first verificationinformation is used for making a payment verification for a verificationrequest.

In some embodiments, after the aforementioned first client-terminalreceives the verification information that the user inputs, it generatesthe first verification information and sends the first verificationinformation to the server, so as to make the server to verify it. Insome embodiments, the first client-terminal can send the verificationinformation to the server through a computer network, a communicationnetwork and other ways. In some embodiments, the verificationinformation entered by the user may be pre-processed by the firstclient-terminal to become the first verification information that issent to the server. For example, the user may enter voice informationand the first client-terminal may gather such voice information with amicrophone; thereafter the voice information may be pre-processed togenerate voiceprint information that is the first verificationinformation to be sent to the server. On the other hand, the voiceinformation gathered by the first client-terminal may be directly sentto the server as the first verification information, and the server mayprocess the voice information to obtain voiceprint information.

S205: The server sends the payment confirmation request to the secondclient-terminal corresponding to an associated communication account ofthe payment account after the verification for the first verificationinformation is passed, wherein the second client-terminal iscorresponding to the associated communication account of the paymentaccount.

In some embodiments, the server may extract and analyze the verificationinformation included in the first verification information. In someembodiments, the server may use the first verification informationdirectly for verification. Then, the server may compare the verificationinformation with the stored respective verification information of thisfirst client-terminal registered for this payment account. If the twosets of information are the same, the verification passes; otherwise,the verification fails and the server sends an error message. In someembodiments, the first verification information may include firstvoiceprint information, the verification of the server for the firstverification information may include: the server compares the firstvoiceprint information with respective voiceprint information storedwith the server in association with the payment account.

In some embodiments, the step S205 can include: the server conductsverification for the first verification information; if the verificationis passed, the server searches for the associated communication accountconfigured for the payment account; the server sends the paymentconfirmation request to the second client-terminal corresponding to theassociated communication account determined by searches.

In some embodiments, the server may search from the aforementionedcontent stored in S201 and S202. As searching for the associatedcommunication account registered for the payment account from the S205,the step may include: the server searches for the associatedcommunication account(s) registered for the payment account; the serveridentifies the voice authentication information of the associatedcommunication account found according to the first voice information,deletes the account corresponding to the first voice information fromthe associated communication accounts found, and takes the remainingassociated communication account(s) as the associated communicationaccount(s) determined by the searches.

S206: The second client-terminal responds to the payment confirmationrequest and returns the second verification information to the server.

After the second client-terminal receives the request for paymentconfirmation, the second client-terminal may display the correspondinginputting interface; this inputting interface may display the paymentinformation and the interface for requesting to input the verificationinformation. An exemplary user interface of the second client-terminaldisplaying the inputting interface is shown in FIG. 3B.

As shown in FIG. 3B, the second client-terminal may display a secondinformation obtaining interface, which may prompt the user of the secondclient-terminal to input verification information. Here, the inputverification information is voice information; thus, the secondinformation obtaining interface is prompting the user to “Press totalk,” so the second client-terminal may gather the voice informationfrom the user. As indicated above for FIG. 3A, the verificationinformation may be other types of information and the specific promptinglanguage can vary. In addition to the prompt to enter verificationinformation, the second information obtaining interface may also displaythe payment information, including any one or a combination of theinformation items such as: the name and/or identification symbol, suchas a nickname, of the user of the first client-terminal, the price ofthe merchandise and/or service to be purchased, and the name, source,item number, and/or brief description of the merchandise and/or serviceto be purchased. Such information may also allow the second user of thesecond client-terminal to determine whether the transaction should beapproved. In some embodiments, as shown in FIG. 3B, the secondclient-terminal may further display a “Direct Denial” button, allowingthe user of the second client-terminal to deny transaction withoutentering the verification information. In this case, the user mayapprove the transaction by inputting the verification information.However, it can also be set up so that even when the user of the secondclient-terminal wants to deny the transaction, he/she still needs toenter the verification information, just as when he/she wants to approvethe transaction. In that case, the second client-terminal may displaytwo buttons; “Press to talk and approve,” and “Press to talk and deny.”It should be noted that the specific design of the display of the secondclient-terminal may vary according to a default design andconfigurations by the user.

S207: The server conducts the verification for the second verificationinformation: if the verification passes, the server performs the paymentoperation for the payment account according to the verification requestsubmitted by the first client-terminal.

The specific implementation of S206 and S207 may refer to thecorresponding steps in FIG. 1, as described above, and redundantdescriptions are avoided.

Optionally, in some embodiments, the methods may also include: theserver may send information related to the cause of verification failureto the first client-terminal in case of verification failure of theserver for the first verification information or the second verificationinformation.

In some embodiments, when the verification for the second verificationinformation fails, the server may inform the first user of the firstclient-terminal that the reason for the verification failure is that thesecond user doesn't finish the verification or the verification isincorrect, so that the first user may act accordingly.

In addition, when payment account replenishment is required, the methodof the present application can also include: the server initiates theprocess where the sum of money is transferred to the payment account inresponse to the replenishment request when receiving the request forreplenishing the payment account; herein, the replenishment requestincludes the request for transferring amount into the payment accountsent by the first client-terminal and/or the second client-terminal.

The initiated replenishment process includes interaction with suchequipments as bank server corresponding to a replenishment account,update of account information of payment account and other stepsincluding transfer prompt and verification.

In some embodiments of the present application, one or multipleassociated communication accounts based on registration and/orconfiguration may complete the verification for the user's paymentthrough at least two verification processes based on information from atleast two respective users. This makes the verification for the user'scurrent identity more reliable during the payment process; as long asthe relevant information of one authentic user is not stolen, anun-authorized user cannot complete the verification of the paymentaccount. The current method is easy to implement in the client-terminal,is convenient for the user to complete the safe and reliable userverification simply and rapidly, and ensures the security of the user'spayment account and property.

Referring to FIG. 5, which is a flow chart illustrative of theinformation verification method according to some embodiments of thepresent application. In some embodiments, the methods of the presentapplication can be implemented by interaction between user terminals anda server. In some embodiments, the methods include:

S301: When the server detects that at least two associated communicationaccounts are configured to provide verification for the registeredpayment account, and each associated communication account hascorresponding voice authentication information, the server labels thispayment account as a multi-user verification account.

In some embodiments, the user can complete the registration of thecorresponding associated communication account of the payment accountand the authentication information in a server running the communicationapplication. The user can also complete the registration of thecorresponding associated communication account of the payment accountand the authentication information in the other register servers.Meanwhile, the server conducting the verification may obtain therelevant payment account and its corresponding associated communicationaccount and authentication information, and completes the labeling ofsuch payment accounts according to these.

S302: The server stores the payment account labeled as the multi-userverification account, its associated communication accounts and thevoice authentication information corresponding to every associatedcommunication account. The users of the associated communicationaccounts may serve as verifiers for the multi-user verification account.

The server can store the payment account, its associated communicationaccounts and the authentication information corresponding to everyassociated communication account in the form of a mapping table, so thatthe server can directly find out the associated communication accountand the authentication information corresponding to each associatedcommunication account upon verification through searching the table inthe follow-up.

In some embodiments, the aforementioned is the registration process ofthe relevant information of payment account in the server in someembodiments. This registration process can be completed at any timebefore the payment account initiates payment. Based on thisregistration, the server may complete the steps associated withverification of the payment account.

S303: Based on the payment account, the first client-terminal sends thefirst verification information to the server, and the first verificationinformation is used for making payment verification for the verificationrequest submitted.

In some embodiments, the first verification information submitted by thefirst client-terminal includes voice verification information, paymentaccount and password information that the first client has currentlyused for login. In other words, the first client-terminal may submit theverification information and payment account and password together withthe first verification information, without any prompting form theserver.

S304: The server conducts the initial verification for the paymentaccount and password information included in the first verificationinformation.

The server may verify if the payment account and password are inaccordance with the pre-registered or pre-configured information; ifyes, the verification passes and the server may execute the followingS305; if no, the server sends out the failure prompt.

S305: If the initial verification is passed, the server may conduct thevoice verification for the first voice information in the firstverification information.

S306: If the voice verification is passed, the server may search for theassociated communication account registered for the payment account.

The verification process of the server is to extract and analyze theverification information included in the first verification information,then compare with the stored verification information of this firstclient-terminal registered for this payment account. If the two sets ofinformation are consistent, the verification passes; otherwise, theverification fails and the server sends out an error message. In someembodiments, the first verification information includes the first voiceinformation, the verification of the payment account with the firstverification information may include: verification of the first voiceinformation in the first verification information by the server for thefirst client-terminal.

S306 may include: the server searches for the associated communicationaccount registered for the payment account; the server identifies thevoice authentication information of the associated communication accountfound according to the first voice information; the server deletes theaccount corresponding to the first voice information from the associatedcommunication accounts found; and the server takes the remainingassociated communication account as the associated communication accountdetermined by searches.

S307: The server sends the payment confirmation request to the secondclient-terminal corresponding to the associated communication accountdetermined by the searches.

S308: After the second client-terminal obtains the second verificationinformation, the second client-terminal returns the second verificationinformation to the server in response to the payment confirmationrequest.

After the second client-terminal receives the request of the paymentconfirmation, it may display the corresponding inputting interface; thisinputting interface may display the related issues of this paymentconfirmation request and the interface for requesting to input theverification information, wherein FIG. 3B may show an example of thedisplay by the second client-terminal before the verificationinformation is entered.

S309: The server conducts the verification for the second verificationinformation; if the verification passes, it may perform the paymentoperation for the payment account according to the verification requestsubmitted by the first client-terminal.

The specific implementation of the S308 and S309 may refer to thecorresponding implementations in the aforementioned FIG. 1, andredundant descriptions are avoided.

Optionally, in some embodiments, the methods may also include: theserver may send information related to the cause of verification failureto the first client-terminal in case of verification failure of theserver for the first verification information or the second verificationinformation.

In some embodiments, when the verification for the second verificationinformation fails, the server may inform the first user of the firstclient-terminal that the reason for the verification failure is that thesecond user doesn't finish the verification or the verification isincorrect, so that the first user may act accordingly.

In addition, when payment account replenishment is required, the methodof the embodiment of the present application can also include: theserver initiates the process where the sum of money is transferred tothe payment account in response to the replenishment request whenreceiving the request for replenishing the payment account; herein, thereplenishment request includes the request for transferring amount intothe payment account sent by the first client-terminal and/or the secondclient-terminal.

The initiated replenishment process includes interaction with suchequipments such as bank server corresponding to replenishment account,update of account information of payment account and other stepsincluding transfer prompt and so on.

In some embodiments of the present application, one or multipleassociated communication accounts based on registration and/orconfiguration may complete the verification for the user's paymentthrough at least two verification processes based on information from atleast two respective users. This makes the verification for the user'scurrent identity more reliable during the payment process; as long asthe relevant information of one authentic user is not stolen, anun-authorized user cannot complete the verification of the paymentaccount. The current method is easy to implement in the client-terminal,is convenient for the user to complete the safe and reliable userverification simply and rapidly, and ensures the security of the user'spayment account and property.

Referring to FIG. 6, which is a flow chart illustrative of theinformation verification method as performed by a server according tosome embodiments of the present application. In some embodiments, themethods in the present application may include:

S401: Receiving the first verification information sent by the firstclient-terminal based on the payment account and using the firstverification information for making payment verification for theverification request submitted.

The first client-terminal can be any computing device such as mobiledevices having network functions, such as tablet computers, telephones,e-readers, remote controls, vehicle devices and wearable devices;through the first client-terminal, the user can browse variouse-commerce platforms and obtain relevant commodities and services.

The user of the first client-terminal completes the payment transactionthrough the registered payment account. The payment account in thepresent application can be a common registered account for a single useror a payment account that can be verified by multiple users. In someembodiments, the first client-terminal and the second client-terminalmay be the same device or terminal. In some embodiments, the firstclient-terminal and the second client-terminal may be different devicesor terminals.

After obtaining the verification request from the user, the firstclient-terminal initiates the payment process which firstly needs theuser to submit information for verification, and the payment processinvolving account transfer may be executed after verification passes.Through the first client-terminal, the user sends the first verificationinformation used for making verification, such as payment verificationfor a financial transaction, for the verification request submitted tothe server based on the payment account. Among which, the firstverification information can include information such as voiceinformation and fingerprint information.

The server may receive the first verification information sent by thefirst client-terminal through computer network or communication network.The first verification information may directly include the verificationinformation of voice information or fingerprint information, etc. andthe payment account and its password, so that the server may directlyexecute the verification for the verification information as well as thepayment account and its password; the server may also trigger the firstverification information carried with the verification information sentby the first client-terminal after the server firstly verifies thepayment account based on the payment account's password sent by thefirst client-terminal.

Before the step S401, the server may also execute the following steps:

When the server detects that at least two associated communicationaccounts are registered to verify a payment account, and everyassociated communication account has the corresponding voiceauthentication information, the server labels this payment account as amulti-user verification account.

The server stores the payment account labeled as the multi-userverification account, its associated communication accounts and therespective voice authentication information corresponding to everyassociated communication account.

S402: The server sends the payment confirmation request to the secondclient-terminal corresponding to the associated communication account ofthe payment account after the verification for the first verificationinformation passes.

After the verification passes, the server may conduct verification ofthe verification request using the associated communication accounts andrespective voice authentication information corresponding to eachassociated communication account.

In some embodiments, the step S402 may include: the server searches forthe associated communication accounts registered for the paymentaccount; the server identifies the voice authentication information ofat least one of the associated communication account found according tothe first voice information; the server deletes the accountcorresponding to the first voice information from the associatedcommunication account, and takes the deleted associated communicationaccount as the associated communication account as the second verifier.The server then sends the payment confirmation request to the secondclient-terminal corresponding to the associated communication account.

The verification by the server may refer to the description of theaforementioned embodiments, and redundant descriptions may be avoided.

S403: Receiving the second verification information from the secondclient-terminal in response to the payment confirmation request.

S404: Verifying the second verification information; if the verificationis passed, the server performs the payment operation for the paymentaccount according to the verification request submitted by the firstclient-terminal.

The specific implementation of the S403 and S404 may refer to thedescription of the corresponding embodiments in the aforementioned FIG.1 and FIG. 5, and redundant descriptions may be avoided.

In some embodiments, when the verification for the second verificationinformation fails, the server may inform the first user of the firstclient-terminal that the reason for the verification failure is that thesecond user does not finish the verification or the verification isincorrect, so that the first user may act accordingly.

In addition, when the payment account replenishment is required, themethod of the embodiment of the present application can also include:the server initiates the process where the sum of money is transferredto the payment account in response to the replenishment request whenreceiving the request for replenishing the payment account; herein, thereplenishment request includes the request for transferring amount intothe payment account sent by the first client-terminal and/or the secondclient-terminal.

In some embodiments of the present application, one or multipleassociated communication accounts based on registration and/orconfiguration may complete the verification for the user's paymentthrough at least two verification processes based on information from atleast two respective users. This makes the verification for the user'scurrent identity more reliable during the payment process; as long asthe relevant information of one authentic user is not stolen, anun-authorized user cannot complete the verification of the paymentaccount. The current method is easy to be implemented in theclient-terminal, is convenient for the user to complete the safe andreliable user verification simply and rapidly, and ensures the securityof the user's payment account and property.

Referring to FIG. 7, which is a flow chart illustrative of theinformation verification method as performed by a second client terminalaccording to some embodiments of the present application. The method ofthe present application may include:

S501: Displaying to the user of the second client-terminal paymentinformation included in the verification request after receiving thepayment confirmation request sent by the server.

The client-terminal of the embodiment of the present application is theaforementioned second client-terminal involved. The server sends thispayment confirmation request so as to obtain the verificationinformation taken as the second verification information, the processmay refer to the description of the embodiments corresponding to theaforementioned FIG. 1, FIG. 2, FIG. 5, and FIG. 6.

S502: Processing the voice information from the user to generate voiceverification information; sending the voice verification information tothe server in response to the payment confirmation request.

The client-terminal may prompt the user of the payment issue informationincluded in the payment confirmation request through an interface, alsorequest the user to input the relevant verification information such asvoice information, etc. After it obtains the relevant verificationinformation, the second client-terminal may send the second verificationinformation to the server through computer network or communicationnetwork, so as to facilitate the server to complete the verification.

In some embodiments of the present application, one or multipleassociated communication accounts based on registration and/orconfiguration may complete the verification for the user's paymentthrough at least two verification processes based on information from atleast two respective users. This makes the verification for the user'scurrent identity more reliable during the payment process; as long asthe relevant information of one authentic user is not stolen, anun-authorized user cannot complete the verification of the paymentaccount. The current method is easy to be implemented in theclient-terminal, is convenient for the user to complete the safe andreliable user verification simply and rapidly, and ensures the securityof the user's payment account and property.

Referring to FIG. 8, which is a flow chart illustrative of theinformation verification method as performed by a server according tosome embodiments.

As shown in step 600, the server may register a payment account as themulti-user verification account. The registration of the multi-userverification account may be a process that requires a number ofinformation exchanges between the server and users of a firstclient-terminal and at least one second client-terminal.

The multi-user verification account refers to an account that requiresmore than one layer of verification. In some embodiments, the multi-userverification account requires verification from different users. In someembodiments, the multi-user verification account may be a paymentaccount and a user may be a person authorized to access the paymentaccount. The payment account may be a bank account of other accounttypes that can transfer and receive funds. The payment account may beassociated with a communication account established with a communicationservice provider (e.g., a social network service provider), and can beaccessed via a communication software (e.g., a social network clientapplication, or instant messaging application). In some embodiments, thepayment account and the communication account may be a same accounthaving multiple functions. The payment account and/or the communicationaccount may also be associated with a terminal device. The user of thepayment account (multi-user verification account after registration) mayalso be the user of the communication software. In some embodiments, theusers are persons having biometric characteristics. In addition toaccounts related to financial transactions, the multi-user verificationaccount may be any account that requires a higher level of security. Apayment account and a financial transaction may serve as examples toshow how the multi-user verification account may be registered and how averification process can be carried out for an online transaction.

To initiate the registration process, a first user of the paymentaccount may send a registration request to the server, requesting theserver to register the payment account as a multi-user verificationaccount. The registration request may or may not include a number ofinformation items such as but not be limited to: information related tothe payment account so that the payment account can be identified,information related to a primary communication account associated withthe payment account such as the related communication accounts,designation of a first user as a first verifier, designation of a seconduser who can serve as a second verifier or a number of users who canserve as alternative second verifiers, respective verificationinformation for the first user, and an authentication code for thesecond user.

In some embodiments, the registration request may include any one or acombination of information items. For example, the registration requestmay include first registration information comprising the respectiveverification information used to verify the first verificationinformation received from the first user. In some embodiments, theinformation items may be replaced or modified. For example, instead ofdesignating one or more second verifiers by the first user, the secondverifiers may be selected by the server through certain presetprocedures. For instance, for the communication program running thecommunication accounts, some communication accounts may be set as “goodfriends” or “buddies” or various other categories that may entailspecial relationships, whereas such communication accounts may be usedby the server to identity the users as valid second verifiers. Theserver may select one or a number of such associated communicationaccounts and their users as the second verifiers. The selection may be arandom process or may be based on a preset rule. For example, the servermay select accounts and users only from the category “family members,”or from the category “parents,” when such categories exist. In someembodiments, the server may select one more communication accounts fromthe contact list of the first user's communication account.Subsequently, the server may set the users of the selected communicationaccounts as additional verifiers or allow the first user to choose fromthe selections.

In some embodiments, the step of initiating registration may includemore than one exchange between the server the first user. For example,the server may receive a registration request from a first user, whereinthe registration request only indicates that the user wishes to registerthe payment account as a multi-user verification account. Then theserver may send out prompting messages and information requests to theterminal so that the user may make selection and/or input information toadvance the registration process. For example, the server may first askthe first user to designate which payment account is to be registered;the server may also ask the first user to designate one or more otherusers as the verifier; the server may also request the first user tochoose the form of verification information, e.g. fingerprint or voiceprint; and the server may further prompt the user to enter theverification information. In some embodiments, when the server selectsthe second verifier, the server may ask the first user to confirm thatthe server's selections are acceptable. In some embodiments, the servermay provide a list of identified candidates, e.g. from the first user'scontact list or a specific category of contacts, and ask the first userto select one or more from the list as the second verifier(s). The listmay be presented to the first user as a chart or a drop-down menu in thefirst client-terminal.

In some embodiments, the server may also determine whether thedesignated verifiers by the first user are eligible. For example, theserver may follow a predetermined rule that the verifiers are distinctpersons from the first user. To determine that a verifier is a person,the server may request the verifier to enter physiological biometricinformation indicating a person being present. To determine whether theverifier is distinct from the first user, the server may comparehistorical data related to the verifier and the first user. For example,the server may reject any request that indicates that first user and theverifier are using the same terminal device or are the same person. Inaddition, the server may profile the browser and/or communicationhistory of the first user and the verifier to identify suspiciouspatterns. In some embodiments, the server may reject any verifier orfirst user that has a browsing or communication history—history usingthe communication software—for less than a certain period. e.g. threedays, or a browsing or communication history that is scanty, e.g. lessthan 10 logins within the past 30 days. In general, the server may setany criteria for the eligibility of the verifier.

After receiving the registration request, the server may store therespective verification information included in the registration requestfrom the first user so future verification information submitted by thefirst user may be compared with the stored information. In someembodiments, the server may save the first registration informationentered by the first user in association with the multi-userverification account. In addition, the server may send a registrationconfirmation request to one or more of the second verifiers designatedby the first user or selected by the server.

In some embodiments, in response to the registration request from thefirst user, the server may contact at least one second user to obtainsecond registration information from the at least one second user. Insome embodiments, the second registration information comprises therespective verification information used to verify the verificationinformation submitted by the second user during a later verification fora transaction.

In some embodiments, as shown in FIG. 4A, the terminal device associatedwith the second user displays a confirmation request interface, whichindicates in the second client-terminal that the first user hasdesignated the second user as a second verifier for the payment account.The second user may “Agree” to be the second verifier, “Decline” to bethe second verifier, “Call” the first user, or “Demand authenticationcode” from the server.

The options “Call Zhang San” and “Demand authentication code” serve asexamples that the second user may choose to request further verificationfrom the first user and/or from the server that he/she is dealing with alegitimate request. From the second user's perspective, a request thatsuddenly appears on his/her terminal device without prior notice mayseem suspicious. Therefore, the second user may want to verify therequest by calling the first user before making a decision as to whetherto be a second verifier. In addition, the second user may also ask theserver to provide an authentication code submitted by the first user. Anauthentication code may have been provided to the second user by thefirst user through messages, in person, emails, phone calls, by a prioragreement, or other means. Thus, when the server extracts theauthentication code from the registration request and sends the code tothe second user; the second user may compare the code from the serverwith the code from the first user and determine whether the server ismaking a legitimate request. After the second user determines that theconfirmation request is not scam, he/she can continue with theregistration process.

It should be noted that the specific design of the interfaces andbuttons herein presented may be modified according to the specific needsof the users and the convenience/security requirements. For example, theserver may send a confirmation request to the second user together witha request that the second user enter verification information.

As shown in FIG. 4B, the terminal device associated with the second userdisplays a confirmation request interface, which indicates in the secondclient-terminal that the first user has designated the second user as asecond verifier for the payment account and asks the second user toenter verification information for registration. The second user mayagree to be the second verifier and “press to talk” to enter voiceinformation as the verification information; the second user may also“decline” to become the second verifier; and the second user also agreeto be the second verifier but “choose another verification format.” The“choose another verification format” button may include a drop-down menu(indicated by the triangle at the corner of the button) that allows thesecond user to choose verification formats from a list, such as but notbe limited to: scan fingerprint, e.g. left index finger, scan retina oriris, enter pass code, and other verification formats related orunrelated to biometrics of the second user.

In some embodiments, the first user and the second user enter the sametype of verification information, e.g. voice information. In someembodiments, the first user and the second user enter different types ofverification information, e.g. voice information for the first user andpass code for the second user. In some embodiments, the first userand/or the second user may choose more than one type of verificationinformation.

It should be noted that for the embodiment shown in FIG. 4B, theinterface may still further include options for the second user tochoose to contact the first user and/or demand further confirmation fromthe server, as shown in FIG. 4A.

There may be more than two verifiers. In some embodiments, themulti-user verification account may have three or more verifiers thatare tiered or ranked. In some embodiments, the verifiers are ranked andthe highest ranking verifier may serve as the second verifier. When averifier is not available, the next ranking verifier may serve in itsplace. In some embodiments, the verifiers are tiered and the tiers areranked, and the second verifier is selected from the next ranking tier.Having more than two verifiers may reduce the problem that theverification cannot be successfully conducted because the secondverifier is not available or does not have access to the Internet. Insome embodiments, the verification may require more than two verifiers.For example, in some embodiments, the transaction can only be completedwhen the server receives verification information from three verifiersand all the verification information is consistent with the respectiveverification information submitted by the verifiers during theregistration process.

After receiving the respective second verification information from theat least one second user, the server may save the second registrationinformation entered by the second user in association with themulti-user verification account, establishing the first user as theprimary verifier and the at least one second user as at least oneadditional verifier for online transactions associated with themulti-user verification account. In some embodiments, the server mayidentify the first user not as the primary verifier but as a second orthird verifier, whereas the at least one second user is identified asthe primary verifier.

After the registration process is completed, the server and the clientdevices may be ready to verify the multi-user verification account fortransactions.

As shown in step S601 of FIG. 8, the server may receive a verificationrequest from a first user.

In some embodiments, the verification request may comprise transactioninformation for a pending online transaction and first verificationinformation. The verification request may be used for any transaction orfunction as long as the transaction request results in a verificationprocess related to certain accounts. In some embodiments, thetransaction information of the verification request is related to apending online transaction. For example, the pending online transactionmay be a financial transaction. For example, the financial transactionmay be related to a purchase of certain merchandise or service by thefirst user. The first verification information may include informationsuch as but not limited to: password or other pass code related to anaccount, physiological biometric verification information related to anauthorized user of an account, and other information related to theverification of an account. The physiological biometric verificationinformation, as indicated above, may be any information related tobiometrics such as but not limited to: finger print, iris, facefeatures, voice print, nucleotides such as DNA, palm print, handgeometry, retina, and odor/scent.

In some embodiments, the transaction information may identify amulti-user verification account specifying the first user as a primaryverifier and at least one second user as at least one additionalverifier for the pending online transaction. As indicated above, themulti-user verification account may be a registered payment account thathas been registered with the server as an account that requiremulti-user verification for all or selected forms of transactions. Inaddition to accounts related to financial transactions, the multi-userverification account may be any account that requires a higher level ofsecurity. In some embodiments, the multi-user verification account maybe an account that requires more than one layer of verification, whereinthe verification information is provided by more than one user.

In some embodiments, the multi-user verification account storesrespective verification information for the first user and the at leastone second user. As indicated above, the registered multi-userverification account may store respective verification information thatis accessible by the user and the stored respective verificationinformation can be used to compare with the verification informationspecifically submitted in a verification request for a transaction.

As shown in step S602 of FIG. 8, in response to the verification requestfrom the first user, the server may request additional confirmation forthe pending online transaction from the at least one second user basedon the multi-user verification account.

In some embodiments, the server may first identify the multi-userverification account based on information included in the verificationrequest. Then, the server may send a confirmation request to the atleast one second user, asking the second user to confirm thetransaction. As indicated above, the second user and first user may bedistinct persons. In some embodiments, the second user may be selectedfrom a number of registered users that may serve as verifiers.

In some embodiments, the server may send the confirmation requestwithout verifying the first verification information. For suchimplementations, the server may verify the first verificationinformation and second verification information to be submitted by thesecond user after the first verification information and secondverification information are all properly gathered. On the other hand,the server may also conduct verification of the first verificationinformation before sending out the confirmation request to the seconduser. For example, the server may compare the first verificationinformation submitted by the first user for the online transaction tothe respective verification information from the first user during theregistration process. If the verification is successful, the server maysend the confirmation request to the second user. In suchimplementation, the server avoids disturbing the second user when thefirst verification information cannot be verified successfully. When thefirst verification information cannot be verified successfully, theserver may notify the first user to re-submit the first verificationinformation or ask the first user to re-submit the verification request.

The confirmation request to the second user may include a number ofinformation items. In some embodiments, the confirmation request mayinclude the transaction information so that the second user is informedas to what transaction is pending. In addition, the confirmation requestmay notify the second user about the first user, who initiated theverification process.

As shown in step S603 of FIG. 8, the server may receive secondverification information from the at least one second user, wherein thesecond verification information is provided in response to the requestfor additional confirmation from the server.

As indicated above, the first verification information and the secondverification information may take the same or different forms. And thefirst user and/or the second user may choose to submit different formsof first verification information and second verification information.

As shown in step S604 of FIG. 8, the server may verify the pendingonline transaction in accordance with a comparison of the first andsecond verification information against the respective verificationinformation stored in association with the multi-user verificationaccount.

As shown in FIG. 3A, FIG. 3B, FIG. 1-2 and FIG. 5-7, and also referringto FIGS. 4A and 4B, the second user may approve or deny the transaction.For approval, the second user may need to enter the second verificationinformation so that the multi-user verification account can be fullyverified. In some embodiments, the submission of the second verificationinformation implies that the second user approves the transaction.However, in some embodiments, the second user may also deny thetransaction. If the comparison of the first and second verificationinformation against the respective verification information stored withthe multi-user verification account shows that the verificationinformation is consistent, the server may conduct the transaction basedon the transaction information included in the verification request.Similarly, for any other type of verification request related to anyother types of transaction, the server may conduct the transaction whenthe verification of the transaction is successful.

In some embodiments, the second user may deny the confirmation requestwithout entering the second verification information. Alternatively, thesecond user may deny the confirmation request and enter the secondverification information, wherein the server may terminate thetransaction based on the second user's denial and the secondverification information. In some implementations, the server mayreceive an approval or a denial of the pending online transaction fromthe second user along with the second verification information from theat least one second user and the server may deny the pending transactionif the second verification information comprises a denial of the pendingonline transaction and if the second verification information passes thecomparison. When the verification fails, the server may not complete thetransaction even if the response from the second user includes anapproval. When the verification fails or when the response from thesecond user includes a denial, the server may terminate or suspend thetransaction.

In some embodiments, when the verification is successful, the server maysend a notifying message to the first user and/or the second user, inaddition to the conduction of the transaction. The notifying message mayindicate to the first user and/or second user that the transaction hasbeen approved and/or finished. On the other hand, when the verificationis not successful and/or the response from the second user includes adenial, the server may also send a notifying message to the first userand/or the second user, in addition to the termination and/or suspensionof the transaction. In the case of a suspension, the server may alsoprompt the second user to enter the verification information again.

As indicated above, there may be more than two verifiers. In someembodiments, there may be more than one second verifier. For example,for the second user there may be at least one group of alternativeverifiers where each user included in a respective group of alternativeverifiers is allowed to provide the additional verification on behalf ofthe respective group. In some embodiments, the server may select,randomly or according to a predetermined rule, one verifier from thegroup as the second verifier and send the confirmation request to thisverifier. When the selected verifier is unavailable or declines toprovide the verification information, the server may select anotherverifier from the group to continue the verification process.

Referring to FIG. 9, which is a schematic illustration of an informationverification method, showing how a first client-terminal, a secondclient-terminal, and a server interact according to some embodiments ofthe present application. The method shown in FIG. 9 may be correspondingto embodiments and variations of the information verification method asshown in the aforementioned FIG. 1 to FIG. 8. In some embodiments, themethod shown in FIG. 9 may include:

S1: The first client-terminal sends the first verification informationfor an online transaction to the server.

S2: The server verifies the first verification information; when theverification passes, the server may execute S3, otherwise, the servermay send an error message to the first client-terminal and terminate orsuspend the transaction.

S3: The server may search the associated communication accounts of thepayment account after the server passes the verification for the firstverification information.

S4: The server sends the payment confirmation request to the associatedcommunication account determined by the searches;

S5: The second client-terminal obtains the second verificationinformation from the user; the second client-terminal is theclient-terminal of the associated communication account being used toverify the transaction, wherein the associated communication account maybe a relevant IM application account that has been logged in, and thecommunication account may also be the relevant phone number that hasbeen used.

S6: The second client-terminal returns the second verification to theserver:

S7: The server verifies the second verification information; after theverification passes, the server may execute S8, otherwise, the serverreturns error information to the first client-terminal, and the errorinformation indicates that the second verification information from thesecond client-terminal cannot be successfully verified.

S8: The server executes the payment operation after the server passesthe verification for the second verification information, completing thecurrent transaction.

FIGS. 10-14 illustrate the devices and systems that may be used toperform the methods described above. To avoid redundancy, not all thedetails and variations described for the method are herein included forthe devices and systems. Such details and variations should beconsidered included for the description of the devices and systems aslong as they are not in direct contradiction to the specific descriptionprovided for the devices and systems.

FIG. 10 is the structural schematic view of an information verificationsystem in accordance with some embodiments. The system includes: firstclient-side 1, server 2 and at least one second client-side 3. Thementioned first client-side 1 and the mentioned second client-side 3 maybe in one same user terminal in some embodiments. The mentioned firstclient-side 1 and the second client-side 3 complete the relevantfunctions through the relevant application module. The functions of thefirst-client side 1 and the second client-side 3, and the server 2,perform respective functions described above with respect to the firstclient terminal, the second client terminal, and the server.

FIG. 11 is a block diagram of an information verification apparatus,such as a server, according to some embodiments of the presentapplication. The information verification apparatus may comprise: one ofmore processors; memory; and one or more programs modules stored in thememory and configured for execution by the one or more processors.

In some embodiments, the one or more program modules may include a firstreceiving module 21 configured to receive a verification request from afirst user, wherein the verification request comprises transactioninformation for a pending online transaction and first verificationinformation, wherein the transaction information identifies a multi-userverification account specifying the first user as a primary verifier andat least one second user as at least one additional verifier for thepending online transaction, and wherein the multi-user verificationaccount stores respective verification information for the first userand the at least one second user.

In some embodiments, the one or more program modules may include arequesting module 22 configured to request additional confirmation forthe pending online transaction from the at least one second user basedon the multi-user verification account and in response to theverification request from the first user. In some embodiments, thepending online transaction is an online purchase transaction, and therequesting module 22 is further configured to send purchase orderinformation associated with the online purchase transaction to the atleast one second user when requesting additional confirmation for thepending online transaction from the at least one second user.

In some embodiments, the one or more program modules may include asecond receiving module 23 configured to receive second verificationinformation from the at least one second user, wherein the secondverification information is provided in response to the request foradditional confirmation from the server.

In some embodiments, the one or more program modules may include averifying module 24 configured to verify the pending online transactionin accordance with a comparison of the first and second verificationinformation against the respective verification information stored inassociation with the multi-user verification account.

In some embodiments, the second receiving module 23 is furtherconfigured to receive an approval or a denial of the pending onlinetransaction from the second user along with the second verificationinformation from the at least one second user. In addition, theverifying module 24 is configured to: verify the pending onlinetransaction in accordance with a comparison of the first and secondverification information against the respective verification informationstored in association with the multi-user verification account, and denythe pending transaction if the second verification information comprisesa denial of the pending online transaction and if the secondverification information passes the comparison.

Furthermore, in some embodiments, the one or more program modules mayfurther comprise a processing module 25 that is configured to mark thepayment account as the multi-user verification account when aregistration process is completed. Furthermore, in some embodiments, theprocessing module 25 is also configured to verify payment account withpassword submitted by the first user. In some embodiments, theprocessing module 25 may be configured to conduct the transaction whenthe verifications for the multi-user verification account aresuccessful. For example, the processing module 25 may be furtherconfigured to conduct a financial transaction based on the transactioninformation when the verification of the pending online transaction issuccessful.

In some embodiments, the one or more program modules may further includea registration module 26 configured to register the multiple-userverification account, wherein the registration module 26 comprises: aregistration receiving unit configured to receive a registration requestto register the multi-user verification account from the first user,wherein the registration request includes first registration informationcomprising the respective verification information used to verify thefirst verification information received from the first user; a firstsaving unit configured to save the first registration informationentered by the first user in association with the multi-userverification account; a contacting unit configured to contact the atleast one second user to obtain second registration information from theat least one second user in response to the registration request fromthe first user, wherein the second registration information comprisesthe respective verification information used to verify the secondverification information received from the at least one second user; anda second saving unit configured to save the second registrationinformation entered by the second user in association with themulti-user verification account, establishing the first user as theprimary verifier and the at least one second user as at least oneadditional verifier for online transactions associated with themulti-user verification account.

In some embodiments, the respective verification information stored inassociation with the multi-user verification account comprisesrespective physiological biometric information, such as voiceprint orfingerprint information, associated with the first and the at least onesecond user. In some embodiments, the contacting unit is furtherconfigured to prompt the second user to enter physiological biometricinformation as the second registration information. In some embodiments,the contacting unit is further configured to obtain an approval from thesecond user to register as an additional verifier for onlinetransactions of the first user.

In some embodiments, the first user selects the at least one second useras at least one additional verifier for the multi-user verificationaccount. In some embodiments, the server selects the at least one seconduser as at least one additional verifier for the multi-user verificationaccount in accordance with predetermined rules.

In addition, in some embodiments, the registration module 26 may furthercomprise a registration verifying unit configured to prior to verifythat the first user and the second user are distinct persons prior toestablishing the first user as the primary verifier and the at least onesecond user as at least one additional verifier for online transactionsassociated with the multi-user verification account.

FIG. 12 is a block diagram of an information verification apparatus,such as a second terminal associated with the first client-terminal,according to some embodiments of the present application. The secondterminal may comprise: one of more processors; memory; and one or moreprograms modules stored in the memory and configured for execution bythe one or more processors.

In some embodiments, the one or more program modules may include aconfirmation request receiver module 31, configured to receiveconfirmation requests from a server, wherein the confirmation requestprovide the transaction information related to an online transaction andasks the second user to provide second verification information forfurther verification.

In some embodiments, the one or more program modules may include a datagathering module 32, configured to gather data related to the secondverification information from the second user. In some embodiments, thedata gathered is processed before being sent to the server.

The data gathering module 32 may prompt the user of the secondclient-terminal to respond to the payment confirmation request throughan information obtaining interface, and request the user to input therelevant verification information such as voice information. After therelevant verification information is obtained, the response module 32may send them to the server through computer network or communicationnetwork, so as to facilitate the server to complete the verification.

In some embodiments, the one or more program modules may include aresponse module 33, configured to return the second verificationinformation generated in response to the payment confirmation request tothe server.

FIG. 13 is a schematic structural diagram of an information verificationapparatus, such as a server, according to some embodiments of thepresent application.

As shown in FIG. 13, the exemplary information paying terminal 1300typically includes one or more processing units (CPU's) 1301, one ormore network or other communications interfaces 1304, memory 1310, andone or more communication buses 1302 for interconnecting thesecomponents. The communication buses 1302 may include circuitry(sometimes called a chipset) that interconnects and controlscommunications between system components. The user interface 1303 mayinclude a touch screen, or a display and a keyboard. In someembodiments, the user interface 1303 may further include a standardwired interface and wireless interface, e.g. a Wi-Fi interface. Memory1310 may include high speed random access memory and may also includenon-volatile memory, such as one or more magnetic disk storage devices.Memory 1310 may include mass storage that is remotely located from theCPU's 1301. In some embodiments, memory 1310 stores the followingprograms, modules and data structures, or a subset or superset thereof:

-   -   an operating system 1320 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 1325 that is used for connecting        the server 1300 to the client terminals and/or other computers        via one or more communication networks (wired or wireless), such        as the Internet, other wide area networks, local area networks,        metropolitan area networks, and so on;    -   a user interface module 1330 configured to receive user inputs        through the user interface 1303;    -   and one or more information verification programs 1335 including        a number of server-side application modules such as the        following:    -   a first receiving module 21 configured to receive a verification        request from a first user, wherein the verification request        comprises transaction information for a pending online        transaction and first verification information, wherein the        transaction information identifies a multi-user verification        account specifying the first user as a primary verifier and at        least one second user as at least one additional verifier for        the pending online transaction, and wherein the multi-user        verification account stores respective verification information        for the first user and the at least one second user;    -   a requesting module 22 configured to request additional        confirmation for the pending online transaction from the at        least one second user based on the multi-user verification        account and in response to the verification request from the        first user;    -   a second receiving module 23 configured to receive second        verification information from the at least one second user,        wherein the second verification information is provided in        response to the request for additional confirmation from the        server;    -   a verifying module 24 configured to verify the pending online        transaction in accordance with a comparison of the first and        second verification information against the respective        verification information stored in association with the        multi-user verification account;    -   a processing module 25 configured to conduct the transaction        based on the transaction information when the verification of        the pending online transaction is successful; and    -   a registration module 26 configured to register the        multiple-user verification account.

FIG. 14 is a schematic structural diagram of another informationverification apparatus, such as a second client terminal, according tosome embodiments of the present application.

As shown in FIG. 14, the exemplary second client-terminal 1400 typicallyincludes one or more processing units (CPU's) 1401, one or more networkor other communications interfaces 1404, memory 1410, and one or morecommunication buses 1402 for interconnecting these components. Thecommunication buses 1402 may include circuitry (sometimes called achipset) that interconnects and controls communications between systemcomponents. The user interface 1403 may include a touch screen, or adisplay and a keyboard. In some embodiments, the user interface 1403 mayfurther include a standard wired interface and wireless interface, e.g.a Wi-Fi interface. Memory 1410 may include high speed random accessmemory and may also include non-volatile memory, such as one or moremagnetic disk storage devices. Memory 1410 may include mass storage thatis remotely located from the CPU's 1401. In some embodiments, memory1410 stores the following programs, modules and data structures, or asubset or superset thereof:

-   -   an operating system 1420 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 1425 that is used for connecting        the second client terminal 1400 to the server and/or other        computers via one or more communication networks (wired or        wireless), such as the Internet, other wide area networks, local        area networks, metropolitan area networks, and so on;    -   a user interface module 1430 configured to receive user inputs        through the user interface 1403;    -   and one or more information verification programs 1435 including        a number of terminal-side application modules such as the        following:    -   a confirmation request receiver module 31 configured to receive        confirmation requests from a server, wherein the confirmation        request provide the transaction information related to an online        transaction and asks the second user to provide second        verification information for further verification;    -   a data gathering module 32, configured to gather data related to        the second verification information from the second user. In        some embodiments, the data gathered is processed before being        sent to the server; and    -   a response module 33, configured to return the second        verification information generated in response to the payment        confirmation request to the server.

Although some of the various drawings illustrate a number of logicalstages in a particular order, stages that are not order dependent may bereordered and other stages may be combined or broken out. While somereordering or other groupings are specifically mentioned, others may beobvious to those of ordinary skill in the art and so do not present anexhaustive list of alternatives. Moreover, it should be recognized thatthe stages could be implemented in hardware, firmware, software or anycombination thereof.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific embodiments. However, theillustrative discussions above are not intended to be exhaustive or tolimit the present application to the precise forms disclosed. Manymodifications and variations are possible in view of the aboveteachings. The embodiments were chosen and described in order to bestexplain the principles of the present application and its practicalapplications, to thereby enable others skilled in the art to bestutilize the present application and various embodiments with variousmodifications as are suited to the particular use contemplated.

What is claimed is:
 1. A method of multi-user verification for onlinetransactions using an instant messaging (IM) application, wherein the IMapplication having a plurality of IM accounts, the method comprising:receiving a first message including a verification request from a firstuser at a first electronic device running the IM application, whereinthe verification request comprises transaction information for a pendingonline transaction and first verification information and firstbiometric information associated with the first user, wherein thetransaction information identifies the first user as a primary verifierand at least one second user as at least one additional verifier for thepending online transaction; in response to the verification request fromthe first user, comparing the first biometric information againstprestored first reference biometric information associated with thefirst user in association with the first IM account; sending a secondmessage requesting additional confirmation for the pending onlinetransaction from the at least one second user at a second electronicdevice running the IM application after the first biometric informationpassing the comparison; receiving a third message including secondverification information from the at least one second user at the secondelectronic device running the IM application, wherein the secondverification information is provided in response to the request foradditional confirmation from the server; and verifying the pendingonline transaction in accordance with a comparison of the firstverification information and second verification information againstrespective verification information stored in association with the firstuser and the at least one second user.
 2. The method of claim 1,wherein: the pending online transaction is an online purchasetransaction, and the second message requesting additional confirmationfor the pending online transaction from the at least one second userfurther comprises purchase order information associated with the onlinepurchase transaction to the at least one second user.
 3. The method ofclaim 2, further comprising: conducting a financial transaction based onthe transaction information when the verification of the pending onlinetransaction is successful.
 4. The method of claim 1, wherein: therespective verification information stored in association with the firstuser and the at least one second user comprises respective biometricinformation associated with the first and the at least one second user.5. The method of claim 4, wherein: the respective biometric informationassociated with the first user includes a voiceprint of the first user.6. The method of claim 1, further comprising: before receiving the firstmessage including the verification request from the first user:receiving a registration request to register a multi-user verificationaccount from the first user, wherein the registration request includes(i) first registration information used to verify the first verificationinformation received from the first user and (ii) a user accountassociated with the at least one second user as at least one additionalverifier; saving the first registration information entered by the firstuser in association with the multi-user verification account; inresponse to the registration request from the first user, sending amessage to the user account associated with the at least one second userto obtain second registration information from the at least one seconduser, wherein the second registration information comprises therespective verification information used to verify the secondverification information received from the at least one second user; andsaving the second registration information returned by the second userin association with the multi-user verification account, establishingthe first user as the primary verifier and the at least one second useras at least one additional verifier for online transactions associatedwith the multi-user verification account.
 7. The method of claim 6,wherein: the second user provides biometric information as the secondregistration information.
 8. The method of claim 6, wherein: the firstuser selects the at least one second user as at least one additionalverifier for the multi-user verification account.
 9. The method of claim6, further comprising: prior to establishing the first user as theprimary verifier and the at least one second user as at least oneadditional verifier for online transactions associated with themulti-user verification account, verifying that the first user and thesecond user are direct contacts of each other.
 10. The method of claim1, wherein the at least one second user includes at least one group ofalternative verifiers w % here each user included in a respective groupof alternative verifiers is allowed to provide the additionalverification on behalf of the respective group.
 11. The method of claim1, further comprising: receiving an approval or a denial of the pendingonline transaction from the second user along with the secondverification information from the at least one second user, whereinverifying the pending online transaction in accordance with a comparisonof the first verification information and second verificationinformation against respective verification information stored inassociation with the first user and the at least one second user furthercomprises: sending a fourth message to the first user at the firstelectronic device running the IM application denying the pendingtransaction when the second verification information comprises a denialof the pending online transaction and if the second verificationinformation passes the comparison.
 12. A computer system, comprising:one of more processors; and memory storing instructions, theinstructions, when execution by the one or more processors, cause theprocessors to perform operations comprising: receiving a first messageincluding a verification request from a first user at a first electronicdevice running the IM application, wherein the verification requestcomprises transaction information for a pending online transaction andfirst verification information and first biometric informationassociated with the first user, wherein the transaction informationidentifies the first user as a primary verifier and at least one seconduser as at least one additional verifier for the pending onlinetransaction; in response to the verification request from the firstuser, comparing the first biometric information against prestored firstreference biometric information associated with the first user inassociation with the first IM account; sending a second messagerequesting additional confirmation for the pending online transactionfrom the at least one second user at a second electronic device runningthe IM application after the first biometric information passing thecomparison; receiving a third message including second verificationinformation from the at least one second user at the second electronicdevice running the IM application, wherein the second verificationinformation is provided in response to the request for additionalconfirmation from the server; and verifying the pending onlinetransaction in accordance with a comparison of the first verificationinformation and second verification information against respectiveverification information stored in association with the first user andthe at least one second user.
 13. The computer system of claim 12,wherein: the respective verification information stored in associationwith the first user and the at least one second user comprisesrespective biometric information associated with the first and the atleast one second user.
 14. The computer system of claim 12, wherein theoperations further comprise: before receiving the first messageincluding the verification request from the first user: receiving aregistration request to register a multi-user verification account fromthe first user, wherein the registration request includes (i) firstregistration information used to verify the first verificationinformation received from the first user and (ii) a user accountassociated with the at least one second user as at least one additionalverifier; saving the first registration information entered by the firstuser in association with the multi-user verification account; inresponse to the registration request from the first user, sending amessage to the user account associated with the at least one second userto obtain second registration information from the at least one seconduser, wherein the second registration information comprises therespective verification information used to verify the secondverification information received from the at least one second user; andsaving the second registration information returned by the second userin association with the multi-user verification account, establishingthe first user as the primary verifier and the at least one second useras at least one additional verifier for online transactions associatedwith the multi-user verification account.
 15. The computer system ofclaim 14, wherein: the second user provides biometric information as thesecond registration information.
 16. The computer system of claim 14,wherein: the first user selects the at least one second user as at leastone additional verifier for the multi-user verification account.
 17. Thecomputer system of claim 14, wherein the operations further comprise:prior to establishing the first user as the primary verifier and the atleast one second user as at least one additional verifier for onlinetransactions associated with the multi-user verification account,verifying that the first user and the second user are direct contacts ofeach other.
 18. A non-transitory computer readable storage medium havingstored therein one or more instructions that, when executed by aprocessor of a computer system, cause the computer system to perform aplurality of operations including: receiving a first message including averification request from a first user at a first electronic devicerunning the IM application, wherein the verification request comprisestransaction information for a pending online transaction and firstverification information and first biometric information associated withthe first user, wherein the transaction information identifies the firstuser as a primary verifier and at least one second user as at least oneadditional verifier for the pending online transaction; in response tothe verification request from the first user, comparing the firstbiometric information against prestored first reference biometricinformation associated with the first user in association with the firstIM account; sending a second message requesting additional confirmationfor the pending online transaction from the at least one second user ata second electronic device running the IM application after the firstbiometric information passing the comparison; receiving a third messageincluding second verification information from the at least one seconduser at the second electronic device running the IM application, whereinthe second verification information is provided in response to therequest for additional confirmation from the server; and verifying thepending online transaction in accordance with a comparison of the firstverification information and second verification information againstrespective verification information stored in association with the firstuser and the at least one second user.
 19. The non-transitory computerreadable storage medium of claim 18, wherein: the respectiveverification information stored in association with the first user andthe at least one second user comprises respective biometric informationassociated with the first and the at least one second user.
 20. Thenon-transitory computer readable storage medium of claim 18, wherein theoperations further comprise: before receiving the first messageincluding the verification request from the first user: receiving aregistration request to register a multi-user verification account fromthe first user, wherein the registration request includes (i) firstregistration information used to verify the first verificationinformation received from the first user and (ii) a user accountassociated with the at least one second user as at least one additionalverifier; saving the first registration information entered by the firstuser in association with the multi-user verification account; inresponse to the registration request from the first user, sending amessage to the user account associated with the at least one second userto obtain second registration information from the at least one seconduser, wherein the second registration information comprises therespective verification information used to verify the secondverification information received from the at least one second user; andsaving the second registration information returned by the second userin association with the multi-user verification account, establishingthe first user as the primary verifier and the at least one second useras at least one additional verifier for online transactions associatedwith the multi-user verification account.